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Data packet numbering in packet-switched data transmission 

BACKGROUND OF THE INVENTION 

The invention relates to packet-switched data transmission, and 
more precisely, to optimisation of data packet numbering, particularly in con- 
5 nection with acknowledged data transmission. 

One of the aims in the development of third-generation mobile 
communication systems, which are called e.g. the UMTS (Universal Mobile 
Communication System) and the lMT-2000 (International Mobile Telephone 
System), has been as good compatibility as possible with the second- 

10 generation mobile communication systems, such as the GSM system (Global 
System for Mobile Communications). For example, the core network of the 
UMTS system is designed to be built on the basis of the GSM core network, 
which allows as efficient utilization of the existing networks as possible. A fur- 
ther object is to enable third-generation mobile stations to perform handover 

15 between the UMTS and the GSM systems. This also applies to packet- 
switched data transmission, particularly between the UMTS and the packet 
radio network GPRS (General Packet Radio Service) designed for the GSM 
system. 

In packet-switched data transmission we can employ reliable, i.e. 

20 acknowledged, transmission or unreliable, i.e, unacknowledged, transmission. 
In acknowledged data transmission the receiver sends an acknowledgement 
of received data packets PDU (Protocol Data Unit) to the transmitter, and thus 
the transmitter can retransmit lost or damaged packets. When inter-SGSN 
(Serving GPRS Support Node) handover is performed in the GPRS system, 

25 reliability of data transmission is ensured by means of an 8-bit N-PDU number 
(Network PDU) which is attached to data packets and used for checking which 
data packets were transmitted to the receiver. In the UMTS system according 
to the current specifications, a 12-bit RLC sequence number of the RLC layer 
(Radio Link Control) of the packet data protocol is used for guaranteeing reli- 

30 ability of handover between serving support nodes in packet-switched data 
transmission. 

In handover from the GPRS to the UMTS, the UMTS system is re- 
sponsible for reliability of handover. The reliability is checked by means of N- 
PDU numbers of the GPRS, which are used for generating identification num- 
35 bers to be used in the handover process in the UMTS. When handover is per- 
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formed from the UMTS to the GPRS, the GPRS system is responsible for the 
handover, in which case reliability is checked on the basis of the identification 
data of data packets included in the UMTS. For this purpose, an 8-bit data 
packet number has been designed for the UMTS system, which is added as 
5 an additional byte to a data packet of a convergence protocol layer PDCP 
(Packet Data Convergence Protocol) belonging to the UMTS data packet pro- 
tocol. This PDCP-PDU number thus forms a data packet number which logi- 
cally corresponds to the N-PDU number of the GPRS and on the basis of 
which it is checked during handover whether ail data packets have been 

10 transmitted reliably. It is also possible to form the 8-bit PDCP-PDU number 
from 12-bit RLC sequence numbers by removing the four most significant bits. 
Corresponding PDCP-PDU, i.e. N-PNU, numbering can also be used in inter- 
nal handover between radio network subsystems in the UMTS (SRNS Reloca- 
tion). Data packets PDU are inserted into a buffer to wait until handover has 

1 5 been performed to a serving support node SGSN of another system or to a 
new serving radio network subsystem SRSN in the internal handover in the 
UMTS, and the transmitted data packets can be removed from the buffer as 
an acknowledgement of received data packets is received from the receiver. 

A problem related to the arrangement described above is attach- 

20 ment of the additional byte formed by the PDCP-PDU number to the header 
field of each data packet in the convergence protocol layer PDCP. This in- 
creases the load in data transmission because an additional byte is transmit- 
ted in each data packet. In normal data transmission, the UMTS packet data 
service has no use for the PDCP-PDU number; it is only utilized in handover 

25 between the UMTS and the GPRS and in internal handover in the UMTS. 

A further problem related to the arrangement described above is 
generation of PDCP-PDU numbers from RLC sequence numbers. The RLC 
sequence numbers are defined consecutively for the data units RLC-PDU of 
the RLC layer. Due to delay in the system the buffer may contain a large num- 

30 ber of data units RLC-PDU. If the RLC sequence numbers exceed 255, which 
is the largest decimal number that can be represented by eight bits, two or 
more data packets may receive the same PDCP-PDU number because the 
four most significant bits are removed from the twelve bits of the RLC se- 
quence numbers. In that case the receiver cannot unambiguously define the 

35 data packet to be acknowledged on the basis of the PDCP-PDU number of the 
received packet, and reliability of handover can no longer be guaranteed. 
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Possible multiplexing of packet data transmissions in the PDCP 
layer may also constitute a problem because the RLC layer below the PDCP 
layer receives data packets simultaneously from several connections. Since 
the reliability of handover is ascertained on the basis of connection, it is very 
5 difficult to define RLC sequence numbers for several simultaneous connec- 
tions as well as unreliable in view of handover. 

BRIEF DESCRIPTION OF THE INVENTION 

An object of the invention is to provide an improved method and an 
apparatus implementing the method to minimize the above-mentioned disad- 
10 vantages. The objects of the invention are achieved with a method and an ar- 
rangement which are characterized by what is disclosed in the independent 
claims. The preferred embodiments of the invention are disclosed in the de- 
pendent claims. 

The invention is based on using 'virtual' data packet numbering 

15 maintained by counters in data packet numbering in the PDCP layer. Both the 
transmitting PDCP and the receiving PDCP monitor the data packets to be 
transmitted by means of counters, and the receiving PDCP acknowledges re- 
ceived data packets by means of the counter reading, preferably in a manner 
corresponding to normal acknowledged data transmission, in which case data 

20 packet numbers need not be transmitted with the data packets. According to a 
preferred embodiment of the invention, a data packet number can be attached 
to data packets transmitted in poor transmission conditions or due to limita- 
tions of the system at certain intervals. The data packet number is not added 
to each data packet, yet the data packet counters can be synchronized. 

25 An advantage of the method and arrangement of the invention is 

that in optimal transmission situations acknowledged data transmission can be 
guaranteed without having to transmit any data packet number. In non-optimal 
transmission conditions data packet numbers are transmitted in very few data 
packets. Another advantage is that the data packets to be acknowledged and 

30 removed from the buffer can be determined unambiguously. A further advan- 
tage is that the method according to the invention is not applicable only to in- 
ternal handover between radio network subsystems of the UMTS, but also to 
handover between the UMTS and the GPRS, provided that corresponding vir- 
tual data packet numbering will also be introduced into future GPRS versions. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The invention will be described in greater detail by means of pre- 
ferred embodiments with reference to the accompanying drawings, in which 

Figure 1 is a block diagram of the structure of the GSM/GPRS sys- 

5 tern; 

Figure 2 is a block diagram of the structure of the UMTS system; 

Figures 3a and 3b illustrate protocol stacks of user data connec- 
tions in the GPRS and UMTS; 

Figure 4 is a signalling chart illustrating a prior art handover process 
10 from the UMTS to the GPRS system; 

Figure 5 is a signalling chart illustrating acknowledged data trans- 
mission and acknowledgement of data packets in PDCP data transmission; 

Figure 6 is a block diagram illustrating a functional model of the 
PDCP layer; 

15 Figure 7 is a signalling chart illustrating acknowledged data trans- 

mission which utilizes data packet numbering according to the invention, and 
acknowledgement of data packets in PDCP data transmission; 

Figure 8 illustrates the structure of a data packet utilized in the in- 
vention; and 

20 Figures 9a, 9b and 9c illustrate the structure of different data pack- 

ets utilized in the invention. 

DETAILED DESCRIPTION OF THE INVENTION 

In the following, the invention will be explained using as an example 
a packet radio service of the UMTS and GPRS systems. However, the inven- 
tion is not limited to these systems, but may be applied to any packet-switched 
data transmission method which requires acknowledgement of data packets in 
the manner to be described below. The invention is particularly suitable both 
for acknowledged handover between the UMTS and the GPRS and for internal 
handover between radio network subsystems in the UMTS (SRNS Reloca- 
tion). Thus in the former case the term receiving PDCP used in this description 
can be replaced with the corresponding function of the GPRS, i.e. SNDCP. 

Figure 1 illustrates how the GPRS system is built on the basis of 
the GSM system. The GSM system comprises mobile stations MS, which 
communicate with base transceiver stations BTS via radio paths. Several base 
transceiver stations BTS are connected to a base station controller BSC, 
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which controls the radio frequencies and channels available to the base trans- 
ceiver stations. The base station controllers BSC communicate, via an A inter- 
face, with a mobile services switching centre MSC, which is responsible for 
connection set-up/establishment and routing of calls to correct addresses. The 
5 MSC is assisted by two data bases which comprise information on mobile 
subscribers: a home location register HLR which contains information on all 
subscribers of the mobile communication network and on the services ordered 
by them, and a visitor location register VLR which contains information on mo- 
bile stations which visit the are of a certain mobile services switching centre 

10 MSC. The mobile services switching centre MSC communicates with other 
mobile services switching centres via a gateway mobile services switching 
centre GMSC and with a public switched telephone network PSTN. As regards 
a more detailed description of the GSM system, reference is made to 
ETSI/GSM specifications and to The GSM system for Mobile Communications, 

15 M. Mouly and M, Pautet, Palaiseau, France, 1992, ISBN: 2-957190-07-7. 

A GPRS system connected to the GSM network comprises two 
nearly independent functions, i.e. a gateway GPRS support node GGSN and a 
serving GPRS support node SGSN. The GPRS network may comprise several 
serving support nodes and gateway support nodes, and typically several serv- 

20 ing support nodes SGSN are connected to one gateway support node GGSN. 
Both the SGSN node and the GGSN node function as routers which support 
mobility of the mobile station and control the mobile communication system 
and route data packets to mobile stations regardless of their location and the 
protocol used. The serving support node SGSN communicates with a mobile 

25 station MS via the mobile communication network. The connection to the mo- 
bile communication network (Gb interface) is typically established either via 
the base transceiver station BTS or the base station controller BSC. The func- 
tion of the serving support node SGSN is to detect mobile stations capable of 
packet radio connections in its area, send data packets to and receive them 

30 from these mobile stations and to monitor the location of the mobile stations in 
its service area. In addition, the serving support node SGSN communicates 
with the mobile services switching centre MSC and the visitor location register 
VLR via a signalling interface Gs and with the home location register HLR via 
a Gr interface. The home location register HLR also contains GPRS records 

35 which are related to the packet radio sen/ice and include the contents of sub- 
scriber-specific packet data protocols. 
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The gateway support nod GGSN functions as a gateway between 
the GPRS network and an external data network PDN (Packet Data Network). 
External data networks include a GPRS network of another network operator, 
the Internet, an X.25 network or a private local area network. The gateway 
5 support node GGSN communicates with these data networks via a Gi inter- 
face. The data packets to be transmitted between the gateway support node 
GGSN and the serving support node SGSN are always encapsulated accord- 
ing to the GPRS standard. The gateway support node GGSN also contains the 
PDP addresses (Packet Data Protocol) of GPRS mobile stations and the rout- 

10 ing data, i.e. SGSN addresses. The routing data are thus used for linking data 
packets between the external data network and the serving support node 
SGSN. The GPRS core network between the gateway support node GGSN 
and the serving support node SGSN is a network which utilizes the IP proto- 
col, preferably IPv6 (Internet Protocol, version 6). 

15 In packet-switched data transmission the connection offered by the 

telecommunications network between a terminal and a network address is 
commonly called a context. This refers to a logical link between destination 
addresses via which data packets are transmitted between the destination ad- 
dresses. This logical link may also exist even though no packets are transmit- 

20 ted, in which case it does not use the system capacity, which can be reserved 
for other connections. Thus the context differs from a circuit-switched connec- 
tion, for example. 

Figure 2 shows in a simplified manner how the third-generation 
UMTS network can be built in connection with an advanced GSM core net- 

25 work. In the core network the mobile sen/ices switching centre/visitor location 
register 3G-MSC/VLR communicates with the home location register HLR and 
preferably also with the service control point SCP of an intelligent network. 
The connection to the serving support node 3G-SGSN is established via a Gs' 
interface and to the public switched telephone network PSTN/ISDN as de- 

30 scribed above in connection with the GSM. From the serving support node 3G- 
SGSN a connection is established to external data networks PDN exactly in 
the same way as in the GPRS system, i.e. via the Gn interface to the gateway 
support node 3G-GGSN, which is connected to external data networks PDN. 
Both the mobile services switching centre 3G-MSC/VLR and the serving sup- 

35 port node 3G-SGSN communicate with a radio network UTRAN (UMTS Ter- 
restrial Radio Access Network) via a lu interface, which in view of the 
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GSM/GPRS system combines functionalities of the A and Gb interfaces. The 
lu interface can also be provided with totally new functionalities. The radio 
network UTRAN comprises several radio network subsystems RNS which 
consist of radio network controllers RNC and base stations BS, which commu- 
5 nicate with the radio network controllers and are also called node Bs, The 
base stations communicate with user equipment UE, typically with mobile sta- 
tions MS, via radio paths* 

Figures 3a and 3b illustrate protocol stacks of the GPRS and the 
UMTS, respectively. Definitions in accordance with these protocols are used in 

10 the transmission of user data in the systems concerned. Figure 3a shows a 
protocol stack used for transmitting user data between the mobile station MS 
and the gateway support node GGSN in the GPRS system. Between the mo- 
bile station MS and the base station system BSS of the GSM network data are 
transmitted over the Urn interface according to the normal GSM protocol. At 

15 the Gb interface between the base station system BSS and the serving sup- 
port node SGSN the lowest protocol layer has been left open, and an ATM 
protocol or a Frame Relay protocol is used in the second layer. A BSSGP 
layer (Base Station System GPRS Protocol) above the second layer adds 
definitions of routing and quality service and signallings related to acknowl- 

20 edgement of data packets and management of the Gb interface to the data 
packets to be transmitted, 

Direct communication between the mobile station MS and the serv- 
ing support node SGSN is defined in two protocol layers, i.e. in SNDCP (Sub- 
Network Dependent Convergence Protocol) and LLC (Logical Link Layer). The 

25 user data to be transmitted is segmented into one or more SNDC data units in 
the SNDCP layer, in which case the TCP/IP or UDP/IP header field related to it 
can be compressed, if desired. The SNDC data units are transmitted in LLC 
frames to which address and control information relevant to data transmission 
has been added and in which the SNDC data units can be encrypted. The 

30 function of the LLC layer is to maintain a data transmission connection be- 
tween the mobile station MS and the serving support node SGSN and re- 
transmit damaged frames. The serving support node SGSN is responsible for 
routing data packets arriving from the mobile station MS further to the correct 
gateway support node GGSN. A tunnelling protocol (GTP, GPRS Tunnelling 

35 Protocol) is used on this connection for encapsulating and tunnelling all the 
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user data and signalling transmitted via the GPRS core network. The GTP pro- 
tocol is run above the IP utilized by the GPRS core network. 

The protocol stack according to Figure 3b used in transmission of 
packet-switched user data in the UMTS corresponds to a great extent to the 
5 GPRS protocol stack, but there are some significant exceptions. As is seen in 
Figure 3b, in the UMTS the serving support node 3G-SGSN does not commu- 
nicate directly with the user equipment UE t such as a mobile station MS, in 
any protocol layer, but all the data are transmitted via the radio network 
UTRAN. In that case the serving support node 3G-SGSN mainly functions as 

10 a router which transmits data packets in accordance with the GTP protocol to 
the radio network UTRAN. At the Uu interface between the radio network 
UTRAN and the user equipment UE lower-level data transmission occurs ac- 
cording to the WCDMA or the TD-CDMA protocol in the physical layer. In re- 
spect of their functions the RLC and MAC layers on top of the physical layer 

15 resemble the corresponding layers of the GSM; however, some functions of 
the LLC layer have been transferred to the RLC layer of the UMTS. A PDCP 
layer on top of these mainly replaces the SNDPC layer of the GPRS system, 
and the functionalities of the PDCP layer are nearly similar to those of the 
SNDP layer. 

20 The signalling chart in Figure 4 illustrates a prior art handover from 

the UMTS to the GPRS. Handover of this kind is performed when the mobile 
station MS moves during packet data transmission from a UMTS cell to a 
GSM/GPRS cell which uses a different serving support node SGSN. In that 
case the mobile stations MS and/or radio networks BSS/UTRAN make a deci- 

25 sion on handover (step 400). The mobile station sends a routing area update 
request (RA Update Request, 402) to a new serving support node 2G-SGSN. 
The serving support node 2G-SGSN sends an SGSN context request (404), 
which defines mobility management of the mobile station and the PDP context, 
to the old serving support node 3G-SGSN. The serving support node 3G- 

30 SGSN sends an SRNS context request (406) to the radio network subsystem 
SRNS (serving RNS) that has been responsible for the packet data connec- 
tion, or more precisely, to radio network controllers SRNC (serving RNC) of 
the system. In response to the request the SRNS stops sending data packets 
to the mobile station MS, inserts the data packets to be transmitted into a 

35 buffer and sends a response (SRNS Context Response, 408) to the serving 
support node 3G-SGSN. In this connection the radio network subsystem 
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SRNS, for example, defines PDCP-PDU numbers, he. N-PDU numbers, for 
the data packets to be inserted into the buffer. Having received mobility man- 
agement data of the mobile station MS and PDP context data, the serving 
support node 3G-SGSN passes them to the serving support node 2G-SGSN 
5 (SGSN Context Response, 410). 

If necessary, the serving support node 2G-SGSN can authenticate 
the mobile station from the home location register HLR (Security Functions, 
412). The new serving support node 2G-SGSN informs the old serving support 
node 3G-SGSN that it is ready to receive data packets of activated PDP con- 

10 texts (SGSN Context Ack, 414). In response to this the serving support node 
3G-SGSN requests the radio network subsystem SRNS (SRNS Context Ack, 
416a) to forward the data packets inserted into its buffer to the serving support 
node 3G-SGSN (Forward Packets, 416b), which forwards them to the serving 
support node 2G-SGSN (Forward Packets, 418). The serving support node 

15 2G-SGSN updates a PDP context with the gateway support node GGSN in 
accordance with the GPRS system (Update PDP Context Request/Response, 
420). After this, the serving support node 2G-SGSN informs the home location 
register HLR of the new serving support node (Update GPRS Location, 422), 
in which case the connection established by the old serving support node 3G- 

20 SGSN and the radio network subsystem SRNS is disconnected (424a, 424b, 
424c, 424d), the necessary subscriber data are transmitted to the new serving 
support node 2G-SGSN (426a, 426b), and the home location register HLR 
acknowledges the new serving support node 2G-SGSN (Update GPRS Loca- 
tion Ack, 428). 

25 Then the serving support node 2G-SGSN checks the subscriber 

rights of the mobile station MS and its location and establishes a logical link 
between the serving support node 2G-SGSN and the mobile station MS, after 
which the routing area update request made be the mobile station MS can be 
accepted (RA Update Accept, 430). In this connection the mobile station MS is 

30 also informed of which data packets sent by the mobile station MS to the radio 
network subsystem SRNS of the UMTS before the handover process started 
have been received successfully. These data packets are identified with 
PDCP-PDU numbers generated as described above. The mobile station MS 
acknowledges acceptance of the routing area update request (RA Update 

35 Complete, 432), and at the same time the serving support node 2G-SGSN is 
informed of which data packets transmitted by the serving support node 3G- 
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SGSN via the radio network subsystem SRNS before the handover process 
started have been received successfully by the mobile station MS. After this, 
the new serving support node 2G-SGSN can initiate transmission of data 
packets via the base station system BSS (434). 
5 The following table illustrates generation of 8-bit PDCP-PDU num- 

bers from RLC sequence numbers and problems caused by this. 
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It can be seen in the table, for example, how 12-bit decimal num- 

10 bers 94, 350, 606 and 862 are converted into 8-bit numbers by the method 
described above. Since only the eight least significant bits are taken into ac- 
count in the conversion, all the above-mentioned numbers receive the same 8- 
bit binary representation. If the buffer thus contains nearly 900 data units RLC- 
PDU, the data units containing the above-mentioned RLC sequence numbers 

15 receive the same 8-bit representation. When the receiver acknowledges suc- 
cessfully received data packets to the transmitter, the transmitter cannot know 
unambiguously in the basis of acknowledged 8-bit numbers which data packet 
can be removed from the buffer. 

Figure 5 shows how data transmission is acknowledged and how 

20 data packets travel when acknowledged transmission is used in PDCP data 
transmission. A PDCP entity receives a request (PDCP-DATA.request, 500) to 
transmit data packets from the user as well as data packets PDCP-SDU (Ser- 
vice Data Unit) together with the request. Being network layer data packets, 
these packets are also called N-SDUs. The PDCP entity compresses the 

25 header fields of the data packets and sends the resulting data packets to the 
PDCP-PDU RLC layer (RLC-AM-DATA.request, 502) together with the identity 
data of the radio link. The RLC layer is responsible for transmitting (send, 504) 
data packets PDCP-PDU and for acknowledging successful transmission 
(send ack, 506). In the PDCP entity the data packets N-SDU are inserted into 

30 a buffer, from which they are not removed until an acknowledgement (RLC- 
AM-DATA.conf, 508) of successful transmission of data packets to the receiver 
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is received from the RLC layer. The receiving PDCP receives the PDCP-PDUs 
transmitted from the RLC layer (RLC-AM-DATA.indication, 510), in which cas 
the PDCP entity decompresses the data packets PDCP-PDU. Thus the origi- 
nal data packets N-SDU can be restored and will be forwarded to the user 
5 (PDCP-DATA.indication, 512). 

Figure 6 shows a functional model of the PDCP layer in which one 
PDCP entity is defined for each radio bearer. Since in the existing systems a 
separate PDP context is defined for each radio bearer, one PDCP entity is 
also defined for each PDP context, and thus a certain RLC entity is defined for 

10 the entity in the RLC layer In the GPRS system N-PDU numbering is per- 
formed on the basis of the PDP context, for which reason the same principle 
has also been suggested for the UMTS system. In that case the PDCP layer 
would perform corresponding numbering of data packets on the basis of the 
PDCP entity. If similar numbering is used both in the GPRS and in the UMTS, 

15 there should be no problems in the handover between the systems. However, 
this requires addition of one byte to each PDCP data packet, which uses the 
transmission capacity of the UMTS system, particularly because this additional 
byte is needed only in handover between the UMTS and the GPRS and in in- 
ternal handover between the radio network subsystems of the UMTS. 

20 In principle, the functions of the PDCP layer can also be imple- 

mented by multiplexing several PDP contexts in the PDCP layer, in which case 
one RLC entity in the RLC layer below the PDCP layer receives data packets 
simultaneously from several radio bearers. In that case the data packet num- 
bers defined on the basis of the PDCP entity are mixed in the RLC layer and it 

25 is difficult to separate data packets arriving from several radio bearers from 
one another, particularly if the data packet numbering is based on RLC se- 
quence numbering. 

Lossless handover, in which data packets are not lost in the hand- 
over process, is needed in reliable data transmission which utilizes acknowl- 

30 edged transmission. This sets certain requirements for the RLC layer of the 
UMTS system: the RLC layer has to be in the acknowledgement mode and the 
RLC must be able to send the data packets in the right order. If these condi- 
tions are met, reliable handover can be performed from the GPRS to the 
UMTS according to a preferred embodiment of the invention without having to 

35 transmit any data packet number. 
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According to the invention, a PDCP-PDU sequence number is de- 
fined for the first data packet of the packet data connection and a predeter- 
mined numerical value, e.g. 0 f is set as the initial value for this number in the 
counter both in the transmitting PDCP and in the receiving PDCP/SNDCP. The 
5 invention can be advantageously applied both in reliable handover between 
the UMTS and the GPRS and in internal handover (SRNS Relocation) be- 
tween radio network subsystems in the UMTS. In the former case, the term 
receiving PDCP used in this description can be replaced with the correspond- 
ing function of the GPRS, i.e. SNDCP. 
10 The method according to the invention will be illustrated with Figure 

i 7. When the transmitting PDCP receives (700) a data packet PDCP-SDU from 
| the transmitter, it inserts the data packet PDCP-PDU into the buffer and logi- 
| cally adds a PDCP-PDU sequence number (702) to this data packet. The 
| transmitting PDCP transmits the data packet PDCP-PDU and the PDCP-PDU 
15 S J sequence number logically attached to it to the RLC layer (704) and adds one 
(706) to the counter that determines the value of the PDCP-PDU sequence 
number. The RLC layer may also optionally define the ratio between the 
PDCP-PDU sequence number and the last RLC sequence number of the data 
packet and store it in memory (708). The RLC layer is responsible for trans- 
20 mission of PDCP-PDU data packets between the transmitter and the receiver 
; (710), the data packets PDCP-PDU being split into data units RLC-PDU for 
! transmission and numbered with RLC sequence numbers. When the receiving 
;;PDCP receives (712) a data packet PDCP-PDU from the RLC layer, it adds 
; one (714) to the counter that defines the value of the PDCP-PDU sequence 
25 J lumbers and transmits the data packet PDCP-SDU to the next layer (716). An 
; : acknowledgement of a successfully received data packet is sent to the trans- 
j imitter (718) in the RLC layer, and the transmitting RLC transmits this acknowl- 
\ edgement to the transmitting PDCP (720). In response to the acknowledge- 
j ment, the transmitting PDCP removes the data packet PDCP-SDU in question 
30 \ from the buffer (722). The correct data packet PDCP-SDU to be removed is 
l determined preferably by means of a PDCP-PDU sequence number logically 
attached to the data packet. 

Thus data packet numbering according to the invention is preferably 
performed Virtually, which means that no separate data packet numbers are 
35 added to the data packets, but the transmitted data packets are updated on 
the basis of the counters and the receiving PDCP and the transmitting PDCP 
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can ascertain successful transmission of data packets on the basis of counter 
values. Consequently, in an optimal case acknowledgement of data packets 
according to the invention can also be made to correspond to the acknowl- 
edgement of data packets in normal PDCP data transmission described 
5 above. The actual handover process can be performed according to the prior 
art, e.g. as described above in connection with Figure 4. It should be noted 
that even though the invention has been described in connection with a hand- 
over process, the Virtual' data packet numbering according to the invention 
can also be used in normal acknowledged data transmission in which the re- 

1 0 ceiver and the transmitter remain the same, whereas in the handover process 
one party changes. 

In some interference situations, e.g. when the network is congested 
or there is disturbance on the radio path, the RLC layer cannot guarantee ac- 
knowledged data transmission. A maximum value is typically defined for the 

15 transmitting RLC, which is either a number of retransmissions or a period dur- 
ing which the transmitting RLC tries to retransmit the same data packet. If the 
maximum value is exceeded, the RLC layer informs the receiving PDCP of 
this. The transmitting PDCP removes the corresponding data packet from the 
buffer in connection with the next successful data packet transmission. This 

20 also happens when several successive data packets have lost. The lost data 
packets are removed from the buffer when an acknowledgement of the next 
successfully transmitted data packet is received. If the RLC can inform the 
PDCP layer of all lost data packets, the receiving PDCP can update the 
PDCP-PDU sequence number correctly, and thus the sequence number 

25 counters of the transmitting PDCP and the receiving PDCP remain synchro- 
nized. However, in some interference situations the RLC layer cannot guaran- 
tee that the PDCP layer is informed of lost data packets, in which case the 
PDCP-PDU sequence number counters may become asynchronous in the 
transmitting PDCP and receiving PDCP. 

30 According to a preferred embodiment of the invention, this asyn- 

chronization can be corrected by sending a PDCP-PDU sequence number 
with the data packets PDCP-PDU at certain intervals. When the receiving 
PDCP receives a transmitted data packet PDCP-PDU and a PDCP-PDU se- 
quence number attached to it, it compares the PDCP-PDU sequence number 

35 with the counter value, and if necessary, updates the counter value to corre- 
spond to the PPDCP-PDU sequence number of the received data packet. At- 
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tachment of the PDCP-PDU sequence number to the data packet PDCP-PDU 
can be preferably defined in the settings of the system, in which case the 
PDCP-PDU sequence number can be attached to every tenth or to every hun- 
dredth data packet PDCP-PDU, for example. It is also possible to define that 
5 the PDCP-PDU sequence number is always attached to the data packet 
PDCP-PDU in connection with a certain process, e.g. after discard of the data 
packet in the RLC layer described above or after a handover process. Thus 
the PDCP-PDU sequence number does not need to be attached to each data 
packet even in poor transmission conditions but re-synchronization of the sys- 

10 tern can be preferably guaranteed by sending the PDCP-PDU sequence num- 
ber only in some, preferably in very few, data packets. Naturally, data trans- 
mission is not reliable in the situation described above because data packets 
may disappear, but transmission of data packets can be continued because 
the transmitter and the receiver are synchronized rapidly. 

15 Figure 8 illustrates a structure of the PDCP-layer data packet 

PDCP-PDU according to the invention. The data packet PDCP-PDU according 
to the invention can be used both when the PDCP-PDU sequence number is 
omitted from the data packet and when it is added at certain intervals defined 
by the system. The first byte of the data packet PDCP-PDU comprises one bit 

20 (N) whose value indicates whether a PDCP-PDU sequence number will be 
attached to the data packet PDCP-PDU or not. Bit O indicates whether an op- 
timisation algorithm is used for forming a data packet PDCP-PDU. If bit O re- 
ceives value 1 , optimisation is used and it is defined more accurately with a 
12-bit optimisation field (OPT), which contains four bits from the first byte of 

25 the data packet PDCP-PDU and all bits of the second byte. Values of the op- 
timisation field are used for determining the compression method of the 
header field and the data packet type, for example. On the basis of the optimi- 
sation field values the receiving PDCP can perform opposite procedures on 
the data packet, such as decompression of the header field. There are no pre- 

30 determined values for the optimisation field, but the transmitter and the re- 
ceiver always agree on them separately in the negotiation of PDCP parame- 
ters. A PDCP-PDU sequence number field containing one byte, i.e. 8 bits, is 
optional and is used if bit N receives value 1. In that case the PDCP-PDU se- 
quence number is added to the data packet PDCP-PDU. The actual user data 

35 to be transmitted in the data packet are attached after these definitions. 
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The data packet structure described above is only an example of 
how a PDCP-PDU data packet according to the invention can be formed. Al- 
ternatively, the information included in the data packets PDCP-SDU arriving 
from the upper application-level layers can be forwarded from the PDCP layer 
5 using three different data packets PDCP-PDU: PDCP-No-Header-PDU, 
PDCP-Data-PDU and PDCP-SeqNum-PDU, which are illustrated in Figures 
9a, 9b and 9c, respectively. 

According to Figure 9a, the PDCP-No-Header-PDU comprises 
only data, i.e. the PDCP-SDU received from the upper layers as such. Thus 

10 the PDCP layer does not add any information to the PDCP-SDU, in which 
case the whole PDCP-PDU is used for transmitting payload. Consequently, 
the PDCP-No-Header-PDU can be preferably used in acknowledged data 
transmission described above in which data packet numbering is maintained 
by means of counters. 

15 One byte (8 bits) has been added to the PDCP-Data-PDU of Figure 

9b to indicate the PDU type in question and the compression method to be 
applied to the header field of the PDCP-SDU. In fact, the tasks of the PDCP 
layer include functions related to improvement of channel capacity, which are 
typically based on optimisation of data packet header fields by means of vari- 

20 ous compression algorithms. 

The PDCP-SeqNum-PDU of Figure 9c also comprises a corre- 
sponding extra byte for indicating the PDU type and the compression method 
to be applied to the PDCP-SDU header field. In addition to this, a PDCP-PDU 
sequence number with a length of two bytes, i.e. 16 bits, has been added to it. 

25 Both in the PDCP-Data-PDU and in the PDCP-SeqNum-PDU the PDU type is 
indicated with three bits, and thus it separates the PDCP-Data-PDU from the 
PDCP-SeqNum-PDU. The compression method to be used is indicated with 
five bits. 

One of the functions of the PDCP layer is to transmit data packets 
30 PDCP-PDU and, if necessary, PDCP sequence numbers related to the pack- 
ets to a new radio network subsystem in internal handover (SRNS Relocation) 
between radio network subsystems in the UMTS. During the handover the in- 
terference situations described above may render the data packet counters 
asynchronous and cause a situation in which the transmitting PDCP has sent 
35 a data packet (e.g. PDCP-No-Header-PDU) but it has not been transferred to 
the new receiving PDCP. When the maximum value of retransmissions has 
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been exceeded, the discard function of data packets is terminated in the RLC 
layer. The transmitting RLC informs the transmitting PDCP of this, and the 
transmitting PDCP removes the data packet in question from the buffer. As a 
result of this, the receiving PDCP waits for a data packet which is no longer in 
5 the buffer of the transmitting PDCP, and thus data packet counters cannot be 
synchronized. Such an error situation may result in clearing of the radio 
bearer. 

According to a preferred embodiment, the transmitting PDCP is 
made to send a data packet number with the first data packet in the buffer, i.e. 

10 a PDCP-SeqNum-PDU data packet is used. Consequently, the receiving 
PDCP synchronizes its data packet counter with the transmitting PDCP utiliz- 
ing the data packet number sent, which is the quickest possible way to 
achieve synchronization. Furthermore, data transmission can be continued as 
soon as the counters have been synchronized, and it is unnecessary to clear 

15 the radio bearer, which might result in greater loss of information. After syn- 
chronization, data transmission can be continued using the data packet format 
defined for the radio bearer, e.g. PDCP-No-Header-PDCP data packets. 

It is obvious to a person skilled in the art that as the technology ad- 
vances, the inventive concept can be implemented in various ways. The inven- 

20 tion and its embodiments are thus not limited to the examples described above 
but may vary within the scope of the claims. 
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CLAIMS 

1 . A method for transmission of data packets in a packet-switched 
telecommunications system, the telecommunications protocol of which com- 
prises a convergence protocol layer (PDCP, SNDPC) for converting user data 
5 packets into convergence protocol packets, and a link layer (RLC, LLC) for 
transmitting convergence protocol packets (PDCP-PDU) as data units (RLC- 
PDU) and for acknowledging the transmission, characterized by 

defining a data packet number for the convergence protocol pack- 
ets to be sent by a counter, 
10 transferring the convergence protocol packets to be sent to the link 

layer for transmission, 

defining a data packet number for received convergence protocol 
packets by the counter, and 

acknowledging the received convergence protocol packets. 
15 2. A method according to claim 1, characterized by 

receiving a user data packet in the convergence protocol layer of 
the transmitter, 

storing the user data packet in a buffer and defining a convergence 
protocol packet number for the user data packet as the initial value of the 
20 transmitter's counter, 

transferring the convergence protocol packet and the convergence 
protocol packet number linked therewith to the link layer and adding one to the 
value of the transmitter's counter, 

transferring the convergence protocol packet from the transmitter's 
25 link layer without the convergence protocol packet number to the receiver's 
link layer, 

transmitting the received convergence protocol packet from the re- 
ceiver's link layer to the convergence protocol layer and adding one to the 
value of the receiver's counter, 
30 transmitting an acknowledgement of reception of the convergence 

protocol packet from the receiver's link layer to the transmitter's link layer, and 
removing the user data packet from the buffer in response to 
transmitting the acknowledgement of the reception of the convergence proto- 
col packet to the transmitter's convergence protocol layer. 
35 3. A method according to claim 2, characteriz dby 
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adding the convergence protocol packet number defined by the 
transmitter's counter to a convergence protocol packet to be sent in the link 
layer at predetermined intervals in response to the link layer being unable to 
guarantee acknowledged transmission of the convergence protocol packets, 
5 comparing the value of the receiver's counter with the convergence 

protocol packet number of the received convergence protocol packet, and 

updating the value of the receiver's counter to correspond to said 
convergence protocol packet number in response to the values being unequal. 

4. A method according to claim 3, characterized by 

10 adding the convergence protocol packet number defined by the 

transmitter's counter to the convergence protocol packet to be sent in re- 
sponse to performance of a predetermined process of the telecommunications 
system, such as discard of a data packet or handover. 

5. A method according to claim 3 or 4, characterized by 

1 5 removing unacknowledged user data packets from the buffer in re- 

sponse to the fact that the receiver sends an acknowledgement to the trans- 
mitter of reception of a convergence protocol packet corresponding to the user 
data packet sent after the unacknowledged user data packets. 

6. A method according to claim 3, characterized by 

20 adding the convergence protocol packet number defined by the 

transmitter's counter to the convergence protocol packet that is first in the 
transmitter's buffer in response to the fact that at least one unacknowledged 
user data packet has been removed from the transmitter's buffer after the 
maximum value of retransmissions defined in the link layer has been ex- 

25 ceeded. 

7. A method according to any one of the preceding claims, char- 
acterized in that 

said telecommunications system is a packet-switched mobile com- 
munication system, such as the UMTS or the GPRS system, which utilizes 
30 acknowledged transmission. 

8. A method according to claim 7, characterized in that 

the method is applied in handover between the UMTS and the 

GPRS. 

9. A method according to claim 7, characterized in that 

35 the method is applied in handover between radio network subsys- 

tems in the UMTS, 
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10. A packet-switched telecommunications system which comprises 
a terminal (MS, UE) and a fixed network, which comprises a network element 
(SGSN, SRNC) supporting packet-switched data transmission, data packets 
being arranged to be sent between the terminal and the network element in 
5 the telecommunications system and the telecommunications protocol of the 
telecommunications system comprising a convergence protocol layer (PDCP, 
SNDPC) for converting user data packets into convergence protocol packets, 
and a link layer (RLC, LLC) for transmitting convergence protocol packets 
(PDCP-PDU) as data units (RLC-PDU) and for acknowledging the transmis- 
10 sion, characterized in that in the transmission of data packets between 
the terminal and the network element 

a data packet number is arranged to be defined for the conver- 
gence protocol packets to be sent by means of a counter, 

the convergence protocol packets to sent are arranged to be trans- 
1 5 ferred to the link layer for transmission, 

the data packet number is arranged to be defined for received con- 
vergence protocol packets by the counter, and 

received convergence protocol packets are arranged to be ac- 
knowledged. 

20 11. A telecommunications system according to claim 10, char- 

acterized in that 

the transmitter's convergence protocol layer is arranged to receive a 
user data packet, 

the user data packet is arranged to be stored in a buffer and a con- 
25 vergence protocol packet number is arranged to be defined for the user data 
packet as the initial value of the transmitter's counter, 

the convergence protocol packet and the convergence protocol 
packet number linked therewith are arranged to be transferred to the link layer 
and one is to be added to the value of the transmitter's counter, 
30 the convergence protocol packet is arranged to be sent from the 

transmitter's link layer to the receiver's link layer without the convergence pro- 
tocol packet number, 

the received convergence protocol packet is arranged to be trans- 
ferred from the receiver's link layer to the convergence protocol layer and one 
35 is to be added to the value of the receiver's counter, 
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an acknowledgment of reception of the conv rgence protocol 
packet is arranged to be sent from the receiver's link layer to the transmitter's 
link layer, and 

the user data packet is arranged to be removed from the buffer in 
5 response to the fact that the acknowledgement of the reception of the conver- 
gence protocol packet is transmitted to the transmitter's convergence protocol 
layer. 

12. A telecommunications system according to claim 11, char* 
acterized in that 

10 the convergence protocol packet data number defined by the 

transmitter's counter is arranged to be added to the convergence protocol 
packet to be sent at predetermined intervals in response to the link layer being 
unable to guarantee acknowledged transmission of convergence protocol 
packets, 

15 the value of the receiver's counter is arranged to be comparable 

with the convergence protocol packet number of the received convergence 
protocol packet, and 

the value of the receiver's counter is arranged to be updated to cor- 
respond to said convergence protocol packet number in response to the val- 

20 ues being unequal. 

13. A telecommunications system according to claim 12, char- 
acterized in that 

the convergence protocol packet number defined by the transmit- 
ter's counter is arranged to be added to the convergence protocol packet to be 
25 sent in response to performance of a predetermined process of the telecom- 
munications system, such as discard of a data packet or handover. 

14. A telecommunications system according to claim 12 or 13, 
characterized in that 

unacknowledged user data packets are arranged to be removed 
30 from the buffer in response to the fact that an acknowledgement is sent from 
the receiver to the transmitter of reception of a convergence protocol packet 
corresponding to the user data packet sent after the unacknowledged user 
data packets. 

1 5. A telecommunications system according to any one of claims 
35 10to 14, characterized inthat 
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said telecommunications system is a packet-switched mobile com- 
munication system, such as the UMTS or the GPRS system, which utilizes 
acknowledged transmission. 

16. A telecommunications system according to claim 15, char- 
5 acterized in that 

the convergence protocol packet number is arranged to be defined 
by a counter in handover between the UMTS and the GPRS. 

17. A telecommunications system according to claim 15, char- 
acterized in that 

10 the convergence protocol packet number is arranged to be defined 

by a counter in handover between radio network subsystems in the UMTS. 
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